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REMARKS 

Applicants respectfully traverse and request reconsideration. 

Claims 64-105 are currently pending in the present Application. All claims stand rejected 
under 35 U.S.C. § 102(e) as being anticipated by U.S. Patent App. No. 2004/0,148,506 
("Prince"). Applicant respectfully disagrees. Prince is generally directed towards a method and 
apparatus for a non-revealing, do-not-contact list system in which a do-not-contact list of one- 
way hashed consumer contact information is provided to a set of one or more entities (e.g., 
remote entities hosting client applications 400 such as client do-not-contact list applications 
400). (Abstract; K 0033). For example, as shown in FIG. 1 and described in the accompanying 
text in paragraphs 0030-0034, a data collection system 100 collects entries for the do-not-contact 
list. A one-way hashing engine 200 then hashes the information. The resulting hashed value is 
passed on to a master do-not-contact list server 300, which may store the value in the master do- 
not-contact list database 350. Client do-not-contact list applications 400 may then interact with 
the master do-not-contact list server 300 via a network, thus allowing the client do-not-contact 
list applications 400 to obtain new additions or deletions to the do-not-contact list. 

Turning to claim 64, the Office Action alleges that paragraph 0059 of Prince teaches 
"receiving, by a third entity, a first set of encoded e-mail addresses from a first entity, wherein 
said first set of encoded e-mail addresses represents e-mail addresses to which an e-mail message 
could be sent". Applicants respectfully submit, however, that paragraph 0059 does not appear to 
teach "receiving" any type of set, whether the set be encrypted or not. In contrast, paragraph 
0059 of Prince appears to disclose that a client hosting a client application 400 may receive an 
encoded set of e-mail addresses in the form of a do-not-contact list (representing e-mail 
addresses to which an e-mail message should not be sent ) from the master do not-call-list server 
300 operating on another "entity". In other words, paragraph 0059 appears to be silent as to 
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receiving a list of encoded e-mail addresses to which an e-mail message could be sent. Thus, 
Applicants have turned to Prince in its entirety to determine if other portions of Prince disclose 
receiving a set of encoded e-mail addresses, wherein the set represents e-mail addresses to which 
an e-mail message could be sent . Nowhere, however, does Prince, as best understood, appear to 
teach, describe, or suggest receiving a set of encoded e-mail addresses representing e-mail 
addresses to which an e-mail message could be sent . For this reason alone, claim 64 is in 
condition for allowance. 

The Office Action further cites paragraph 0048 as allegedly teaching the claimed method 
of "removing, by said third entity, from said first set of encoded e-mail addresses, each e-mail 
address that is in said second set of encoded e-mail addresses thereby yielding a third set of 
encoded e-mail addresses, where said third set of encoded e-mail addresses represents e-mail 
addresses to which said e-mail message may be sent." As best understood, paragraph 0059 
teaches that a client application 400 (such as a markerter) is capable of comparing a non- 
cncryptcd/non-hashcd/non-encoded value against the do-not-contact list (by receiving the non- 
encrypted/non-hashed/non-encoded value , hashing the one value, and then comparing it to the 
do-not-contact list of hashed values). In contrast, as claimed in claim 64, for example, 
Applicant's claimed "third entity" receives a first set of encoded e-mail addresses to which an e- 
mail message could be sent . If the hashed value is found on the do-not-contact list, it is 
removed. The result, or yield, in this case is a smaller do-not-contact list, and is not a list of e- 
mail address to which said e-mail message may be sent. In other words, paragraph 0048 merely 
describes, at best, a method for removing an entry from a do-not-contact list, which could be 
similar to removing an entry from the claimed second set of encoded email addresses to which an 
e-mail message should not be sent. Because paragraph 0048 appears to teach the opposite of the 
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requisite claim language (receiving a non-encoded set of values and yielding a set of encoded do- 
not-contact values), claim 64 appears to be in condition for allowance. 

Notwithstanding the above shortcomings of the cited references in Prince, Applicants 
also note that the Examiner has directed to "fully consider the references in its entirety as 
potentially teaching all or part of the claimed invention, as well as the context of the passage as 
taught by the prior art or disclosed by the examiner." (Office Action, p. 5). Applicants 
respectfully note that it is the obligation of the Examiner to provide a showing of anticipation 
and not the obligation of the Applicants to distinguish every paragraph in a cited publication. In 
any event, Applicants are unable to find any description, teaching or suggestion in Prince that 
teaches each and every limitation of Applicants' claim 1 . 

For example, as best understood by Applicants, the data collection system 100, one-way 
hash engine 200, master do-not-contact (DNC) list server 300, and its related master DNC list 
database 350 "may be hosted on a single device" or "implemented in a distributed scheme (e.g., 
implemented on multiple devices in a local area network". Regardless of the number of devices 
in which the system 100, engine 200, server 300 and database 350 are implemented, each of the 
above appear to perform one function: generating a master list of hashed entries for the master 
do-not-call list. In other words, each of the above appear to be responsible for generating a list 
of hashed contact information whereby a call or e-mail should not be sent. (]f 0032). 

As also best understood by Applicants, the client applications 400 may reside on a remote 
computers (e.g., of business or individuals). These remote computers are expressly described by 
Prince to be the senders of unsolicited communications or that otherwise store or use contact 
information. (]f 0033). In one embodiment, Prince describes that the client application 400 (also 
known as a client do-not-contact list application 400) can be kept on the computers or other 
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devices of e-mail marketers, flf 0059). As described, such e-mail marketers can use the client 
do-not-contact list application (i.e., client application 400) "to ensure addresses they send e-mail 
to have not requested to be kept free of so called 'spam'", flf 0059). 

In short, Prince appears to teach a two-entity system whereby a master do-not-call list is 
generated by one entity (e.g., data collection system 100, one-way hash engine 200, master do- 
not-contact list server with database 300, 350) and whereby a client do-not-contact list is 
generated by a second entity (e.g., a client application 400 such as the client do-not-contact list 
application). Prince also teaches that the second entity, the client, is the entity that sends bulk e- 
mails after consulting its do-not-call list (generated also by the second entity and based on the 
master do-not-contact list, flf 0033). 

Turning to the claim language, which defines Applicants' invention, claim 64 generally 
requires three separate entities: (1) the first entity is the entity that transmits the first set of 
encoded e-mail addresses to the third entity (the first set of encoded e-mail addresses represent e- 
mail addresses to which an e-mail message could be sent); (2) the second entity is the source of 
an e-mail message; and (3) the third entity is the entity that receives the first set of encoded e- 
mails and that compiles a second set of encoded e-mail addresses (to which said e-mail message 
should not be sent) and removes from the first set of encoded e-mail address each encoded e-mail 
in the second set to yield a third set of encoded e-mails to which said e-mail message may be 
sent. Applicants note that the system described above in Prince is limited to two (and not three) 
entities. 

Additionally, it is noted that the same entity (i.e., the client that hosts the client 
application 400) in Prince is responsible for the source of an e-mail message and is also 
responsible for generating the set of e-mail addresses to which an e-mail may be sent by hashing 
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its list of e-mail addresses to which a message can be sent and comparing the same to a list of 
hashed e-mail address from the master do-not-call server 300. In this manner, and solely for 
purposes of this hypothetical comparison to the claimed language, the client hosting the client 
application 400 is performing the functions of both the claimed first entity and the claimed third 
entity as used by Applicants in claim 64. However, this impermissibly ignores claim language as 
the claimed first and third entities are claimed as different entities. 

If the Examiner disagrees with Applicants' remarks above, Applicants respectfully 
request a particular showing as to where Prince teaches each and every limitation of claim 64. 

For these reasons stated above, Applicants respectfully submit that the claims are in 
condition for allowance and respectfully request that a Notice of Allowance issue in this case. 
Applicants further note that the dependent claims (e.g., but not limited to claims 65-69) are 
dependent on independent claims Applicants believe are in condition for allowance and add 
novel, nonobvious, and patentable subject matter. Therefore, Applicants submit that they are 
also in condition for allowance. 

The Office Action generally states that "jc]laims 70-105 do not teach or define any new 
limitation above claims 64-69 therefore, they are rejected for similar reasons." Applicants 
respectfully disagree. For example, claim 86 claims, among other things, "transmitting, by said 
first entity, said first list of hash coded e-mail addresses to an e-mail address filtration service 
provider; transmitting, by said second entity, said second set of hash coded e-mail addresses to 
said e-mail address filtration service provider." Prince, as best understood, does not teach, 
describe, or suggest a filtration service provider, and even if something within Prince could be 
interpreted as a filtration service provider, Prince, as best understood, certainly does not teach to 
transmit a first list of hash coded e-mail addresses representing e-mail addresses to which an e- 
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mail message could be sent and to transmit a second list of hash coded e-mail addresses 
representing e-mail addresses to which an e-mail message should not be sent to the filtration 
service provider, as claimed. Therefore, Applicants respectfully submit that claims 70-105 are in 
condition for allowance for at least the relevant reasons stated above, among others. 

Applicants respectfully submit that the claims are in condition for allowance and 
respectfully request that a timely Notice of Allowance be issued in this case. The Examiner is 
invited to contact the below listed attorney if the Examiner believes that a telephone conference 
will advance the prosecution of this application. 



Respectfully submitted, 

Date: April 29, 2008 By: 

Robert S. Beiser 
Registration No. 28,687 

Vedder Price P.C. 

222 North LaSalle Street, Suite 2600 
Chicago, Illinois 60601 
phone: (312) 609-7848 
fax: (312) 609-5005 



CHICAGO/#1764351.2 



20 



